S3TC => r600{c,g}

[RavFX]

I will try to revert patch "r600 CS parser fixes".. I have the same error when playing EVE online on random basis (I think it's not so random but... but...)

And I will retest doom3 after.

[RavFX]

Doom3 work after reverting the patch!

[hmmm]

Unfortunately, doom3 is 32-bit only, and compiling 32-bit stuff is a bit of a pain on a 64-bit system. I'll have to wait a while until a later Mesa enters the gentoo compatibility pack.

Why would you recompile the binary?

http://zerowing.idsoftware.com/linux/doom/#head-bbf251e26f02e635b5df3b186f54ac0ae8bafe17

"There are no amd64 builds planned at this time. However the 32 bit binaries will run in a native amd64 environement."

This suggests a mismatch between the kernel drm and the driver.

Care to elaborate?

[pingufunkybeat]

Why would you recompile the binary?

You need 32-bit Mesa (and 32-bit X, and 32-bit everything) to run 32-bit Doom.

Since I'm on Gentoo, I have to compile all of that.

Care to elaborate?

Parts of the driver are in the kernel (drm), and parts in Mesa and DDX. If you are running very new Mesa on top of an old kernel, you often get that message.

[hmmm]

I seem to be getting the same issue from r600g from xorg-edgers/radeon - any eta when the patch will be reverted/fixed in mesa master?

[cb88]

Actually 32bit programs can use 64bit mesa you just have to make sure that your paths are set up correctly iirc its LIBGL_DRIVER_DIR= wherever your drivers are

That was letting me run 32bit wine apps anyway on a 64bit gentoo... I did have most of the 32bit libs installed though except for mesa

[pingufunkybeat]

Are you absolutely sure about that one? 32 bit apps must link against 32-bit libs. That's why the compatibility libs are needed.

Are you sure you didn't have x86-emul libs installed, including mesa?

[netkas]

The only way 32-bit app can use 64-bit dri driver is glx protocol and indirect rendering, but then its limited to 1.4 ogl

[RavFX]

I just read that passing compressed texture work correctly with currend drivers put compressing them is not implemented.

Can et be possible to patch wine in a way to prevend him to compress texture. If it's possible, it can fix a couple of games without touching the drivers..

[kbios]

afaik, s3tc works in mesain two ways:

1)rgb/rgba texture compressed with help of libtxc_dxtn and sent to gpu

2) s3tc compressed texture sent to gpu

so, why not just skip compression in first case, and change texture type to GL_RGB/RGBA

in second case - decompress texture, chnage type and send to gpu

so bye bye s3tc then

Actually As Far As I Know 2) is already implemented in mesa and doesn't have patent issues (since no software decompression is involved). A workaround for 1) was started in this mesa branch http://cgit.freedesktop.org/~csimpso...tc-by-the-book.
I asked Corbin about it, and he said he would ask Ian Romanick to have a look at it. Basically it should do what you said, skip compression and change texture type. I think this would be the best solution as it would avoid the patent problem completely, would not require an external library and would work more or less automatically with all drivers. Also with modern cards VRAM size should not be a problem. Let's hope work on that side progresses.